-
-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up more disk space #1747
Clean up more disk space #1747
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you check how long this takes?
Yeah was wondering the same thing. If it does take a long time, it might be worth looking at |
Also we could look at using a different method to delete to save time |
Or a |
Here is a log file for the steps, but the summary is
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like this? We could do this with more directories. Though am thinking /opt/hostedtoolcache
is the most time consuming
I'll try timing the other way of deleting. Here are the directory sizes.
|
|
Might be worth confirming that |
Sure, I have the final timing logs with a To summarize, for this run
The final free disk space is ~ 49 GB which is less than what I saw earlier (~ 60 GB). Maybe there was an image update that rolled through? The other consideration is that a failure in this step should not stop the build. The
|
Before the last image update there was 30GB left and after the image update there's only 23 GB left. Can we only do the rsync part? |
Thanks Billy! 🙏 Appreciate your effort in exploring this issue Yeah believe there were image updates. Though haven't looked to see if there was a blogpost, release notes, or something about these. Shaving off 10GB is pretty worthwhile in my book (especially given the amount of time spent is pretty low) In terms of ignoring missing directories we could do |
cc @conda-forge/core (in case others have thoughts) |
Thanks everyone! |
@isuruf are you ok merging this? |
Yes |
Co-authored-by: Mike Henry <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Can we add some reference to the PR's OP?
It's always good to have a (ideally very succinct) problem/motivation description with a (hyperlink) reference;
À laFixes disk space issues encountered at <links to feedstocks/builds>
. -
I think we should only do this for the directories that get deleted with high throughput (acc. to numbers from Clean up more disk space #1747 (comment) and Clean up more disk space #1747 (comment) ) i.e.,
/usr/local/lib/android
/usr/local/share/powershell
- (
/usr/lib/jvm
and/usr/share/swift
if need be)
-
Do we have elapsed time numbers for
/opt/hostedtoolcache/CodeQL/
alone? Since that appears to be the largest of/opt/hostedtoolcache
, it could make sense to only delete that one if it's faster to remove than all of its parent directory.
The limited disk space only affects a very small fraction of builds which is why it would create a lot of "unneeded busy work" for nearly all feedstocks. Hence we should be a bit more conservative w.r.t. the time taken here.
It'd also be good to get numbers for disk space freed and time needed (for each of the removed directories) for the final version of this PR. |
I think the suggestion of having a switch to enable the deletion would be a win-win, rather than having to find a balance between some feedstocks that don't build at all, and wasting time for disk clean-up on every feedstock. For affected feedstocks, it doesn't matter if it takes minutes to do the most extensive clean-up (if the alternative is a failing build), and with a switch we wouldn't pay that cost anywhere else. |
@h-vetinari, I agree in principle and that was my first thought too. It is a matter of finding a pragmatic balance. (That being said, if some builds are so wildly inefficient that they still need "moar", we might at some point need such an option... or fix the builds (upstream)... 🤷) |
Guys, we're bike shedding this one a bit. Let's add a switch to turn this on or off and then move on. We can revisit later if we want to do something more detailed. |
My intention was to avoid much bike shedding by going with a "simple and non-negative impacting but sufficient" route.
If you/others (since, to be frank, I won't be the one documenting/maintaining it) are okay with that, fine by me, of course! |
thanks all! excited to see if this helps avoid some disk full issues we saw on qt! |
Thanks all! 🙏 For clarity the There's also a bunch of logs above that Billy generated if you're interested in more details That said, adding a switch makes sense |
I can also make a PR to update the documentation. Is the switch a new field in the |
Yes! A doc pr would be excellent! Thank you! |
Docs added in PR ( conda-forge/conda-forge.github.io#1986 ) |
Checklist
news
entryThis frees up more disk space on the linux image. Items for deletion are taken from
https://github.com/easimon/maximize-build-space
https://github.com/choderalab/espaloma/pull/176/files#diff-17e3400d876978d12bbad517dcf82312b54fa62723408b1ce011b2755458bdafR36-R62
For reference, the linux image (
ubuntu-22.04
) contains software listed in https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md